.github/workflows/release.yml (1)

335-347: ⚡ Quick win

The elevated permissions may be unnecessary for crates.io publishing.

The custom-publish-crates job grants id-token: write and packages: write permissions. However, crates.io publishing only requires the CARGO_REGISTRY_TOKEN secret (which is provided via secrets: inherit).

• id-token: write is for OIDC/trusted publishing (not applicable to crates.io)
• packages: write is for GitHub Packages (not crates.io)

Consider removing the permissions block or restricting it to contents: read unless these elevated permissions are needed for a future use case.

🔒 Proposed fix to remove excessive permissions

   custom-publish-crates:
     needs:
       - plan
       - host
     if: ${{ !fromJson(needs.plan.outputs.val).announcement_is_prerelease || fromJson(needs.plan.outputs.val).publish_prereleases }}
     uses: ./.github/workflows/publish-crates.yml
     with:
       plan: ${{ needs.plan.outputs.val }}
     secrets: inherit
-    # publish jobs get escalated permissions
-    permissions:
-      "id-token": "write"
-      "packages": "write"

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/release.yml around lines 335 - 347, The
`custom-publish-crates` job in the release.yml workflow has unnecessary elevated
permissions. Remove the `permissions` block (containing `id-token: write` and
`packages: write`) from this job since crates.io publishing only requires the
`CARGO_REGISTRY_TOKEN` secret provided via `secrets: inherit`. The `id-token`
permission is for OIDC/trusted publishing which is not applicable to crates.io,
and `packages` is for GitHub Packages which is also not needed. Either delete
the permissions block entirely or replace it with minimal permissions like
`contents: read` if any permission is needed.

.github/workflows/ci.yml (1)

1-81: ⚖️ Poor tradeoff

Consider tightening workflow security posture (optional improvements).

The workflow follows standard patterns but could adopt stricter security practices:

1. Pin actions to commit SHAs: Currently using version tags (@v4, @v3). Pinning to full commit hashes prevents supply-chain attacks via tag hijacking, though it increases maintenance overhead.

2. Restrict workflow permissions: Add a top-level permissions: block to limit the workflow to read-only access. The current default grants broader permissions than needed for CI checks.

3. Disable credential persistence: Set persist-credentials: false in all actions/checkout steps to prevent credentials from being accessible to subsequent steps or artifacts.

🔒 Example hardened configuration

 name: CI
+
+permissions:
+  contents: read

 on:
   pull_request:

     steps:
       - uses: actions/checkout@v4
+        with:
+          persist-credentials: false

For SHA pinning, tools like Dependabot can automate updates.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/ci.yml around lines 1 - 81, Harden the CI workflow by
applying the requested security improvements in the top-level workflow
definition: add a restrictive permissions block, set persist-credentials to
false on every actions/checkout step, and replace the version-tagged action
references used by actions/checkout, arduino/setup-protoc, and
Swatinem/rust-cache with pinned commit SHAs. Keep the existing job structure and
behavior unchanged while updating the workflow configuration.

.github/workflows/publish-crates.yml (1)

8-12: 💤 Low value

The plan input is declared but never used.

The workflow accepts a plan input (described as the cargo-dist release plan) but doesn't reference it anywhere. If the plan determines which packages to publish or provides metadata for the release, consider extracting and using that information. Otherwise, this input can be removed.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/publish-crates.yml around lines 8 - 12, The publish-crates
workflow declares a `plan` input but never uses it; update the `publish-crates`
job/workflow logic to either consume the `plan` value in the relevant publishing
steps (for example in the main publish path that uses cargo-dist release
metadata) or remove the unused `plan` input from the workflow definition if it
is not needed anywhere.